The present invention relates generally to the field of computer programming and, more specifically, to software development environments.
To generate a software program that can be executed or run by a computer, a software developer or programmer typically chooses a programming language, such as BASIC (Beginner""s All-purpose Symbolic Instruction Code), Fortran, C, etc., and writes source code using the keywords, syntax, variable names, data structures, etc. defined by the selected programming language. Each programming language typically defines its own unique syntax and keywords for performing various functions. After the source code has been written, it is typically converted by a compiler into a machine readable format that can be understood by the computer (e.g., object code). If the developer used incorrect keywords or syntax, the source code cannot by compiled successfully.
The source code is typically written with a text editor and organized into a series of lines of code. Although simple programs may only need a few lines of code, complex programs often consume hundreds, thousands or tens of thousands of lines of code. Significant portions of code, moreover, are often required just to generate displayable user interface images or forms, such as text boxes, command buttons, etc. that can be displayed by windows-based computer systems, such as personal computers running the Microsoft Windows(copyright) series of operating systems from Microsoft Corporation of Redmond, Wash. Furthermore, significant editing is often required to make even relatively minor adjustments to such user interface elements (e.g., moving, re-sizing, etc.).
In order to simplify the creation of such user interface images or forms, Microsoft developed and released a programming system known as Visual Basic(copyright). Visual Basic includes a language engine for executing text-based programming statements, and a forms layout package having a plurality of objects or icons representing common user interface elements, such as text boxes, radio buttons, command buttons, scroll bars, etc. When a developer selects one of these objects from a tool palette and places it onto a form window, Visual Basic automatically creates corresponding code to support that object. By eliminating the need to write code just to display conventional interface elements, Visual Basic greatly simplified the creation of programs to be run on Windows-based platforms. These objects are typically stored in one or more dynamic link libraries (DLLs) that are loaded and run as necessary at application run-time. Since Visual Basic is an xe2x80x9copenxe2x80x9d programming languages, meaning that its syntax and command structures are known and available, third-parties have created and marketed a whole range of objects that can be added to a Visual Basic forms window to facilitate the creation of all sorts of different application programs.
With the release of Visual Basic 4.0, Microsoft extended Visual Basic to support software constructs that have certain object-oriented features by basing this release on its Component Object Model (COM). With Visual Basic 4.0, a new type of object, often referred to as a COM or ActiveX control or object was defined. A COM or ActiveX control is basically a component program object based on Microsoft""s COM technologies, which can issue or raise events. With Visual Basic 4.0 and later releases, a developer similarly uses a forms layout package to drag and drop one or more ActiveX controls onto a form window. In addition, by double-clicking an ActiveX control on the form window, a code window is displayed. Inside this code window, the developer may insert text-based programming code to handle the events raised by the respective ActiveX control (i.e., an event handler). This code must comply with the syntactical and keyword constraints defined by Visual Basic in order for it to be properly executed at application run-time. By writing these event handlers, a developer can cause various ActiveX controls to share information and otherwise interact with each other greatly facilitating the creation of application programs.
FIG. 1 illustrates a conventional Visual Basic work space 100 that may be displayed on a computer screen. The work space 100 includes a Form window 102 and a tool palette 104. The tool palette 104 contains a plurality of icons, which represent individual controls, including a vertical scroll control 106 and a text label control 108, among others. A developer may select any of the controls contained on palette 104 to cause the selected control to appear on the Form window 102. By selecting the vertical scroll icon 106, for example, a corresponding vertical scroll image 110 is displayed on the Form window 102. A text label image 112 may be placed on the Form window 102 in a similar manner. At this point, however, there is no inter-relationship between the objects corresponding to vertical scroll image 110 and text label image 112. In order to establish some such relationship (e.g., causing the text label to display the current position of the vertical scroll), the developer must write a subroutine (e.g., an event handler). Each line or statement of the subroutine, moreover, must conform to the syntax and keyword commands of the underlying programming language (e.g., Visual Basic). Specifically, the developer selects the vertical scroll 110, thereby causing a code window 114 to be displayed on screen 100. Inside the code window 114, the developer writes a text-based subroutine 116 that causes the output of the vertical scroll 110 to be displayed in the text label 112.
When this program is subsequently run, images for the vertical scroll bar 110 and the text label 112 will appear on the screen of the user as part of a user interface. The text label 112, moreover, will display the position of the vertical scroll bar 110 (e.g., xe2x80x9c2256xe2x80x9d). If the user moves the slider bar of the vertical scroll, the contents of text label change to display the scroll bar""s new position (e.g., xe2x80x9c3891xe2x80x9d). As shown, with Visual Basic, the developer need not xe2x80x9cwritexe2x80x9d any code to cause the vertical scroll bar image 110 or the text label image 112 to be displayed on the computer screen during run time. In addition, during the programming phase, the developer may move and re-size these user interface elements simply by manipulating their appearance on the Form window 102 (e.g., with a mouse) in a conventional manner. Due to the relative ease with which application programs having user interface elements can be created, Visual Basic has become a highly popular programming tool. However, in order to develop a meaningful application program (i.e., one in which there is some inter-relationship between the user interface elements), the developer must write, in a text-based format, one or more subroutines. Thus, the developer must learn and is limited by the syntax and keyword structures of Visual Basic.
In addition to Visual Basic and its related products (e.g., Visual C++, etc.), several companies have created software development tools that are almost entirely visually oriented. That is, using these tools, a developer can create an executable application program without having to write a single line of text-based code. For example, National Instruments Corporation of Austin, Tex. has created a programming tool called Lab-VIEW(trademark) for creating virtual instruments primarily for use in the instrumentation industry. Hewlett Packard Company of Palo Alto, Calif. has similarly created a programming tool called HP VEE for generating software programs for use in the electronic testing and data acquisition industries.
HP VEE provides a work area in which a developer can create a data flow diagram. The developer typically selects the objects for inclusion in his or her program from a pull-down menu. HP VEE provides a fixed number of these objects which have been tailored to provide functionality commonly used in the data acquisition industry. The developer may then xe2x80x9cdrawxe2x80x9d data lines between these objects in the work area. In response to drawing these lines, HP VEE creates program steps that transfer data or other information between the respective objects. The developer must perform all of this graphically within the work area.
For developers working in the data acquisition field, HP VEE is a useful programming tool. There are some disadvantages nonetheless. For example, to implement functionality that the pre-defined objects do not provide, the developer must typically create a completely new object. Since this can take a significant amount time, it is often not done, unless the desired functionality is critical to the application program. Accordingly, some application programs lack functionality that the developer would have preferred to include. In addition, a graphical approach is not always the most expeditious way to represent or implement certain programs or subroutines.
The present invention recognizes that graphical programming methods inherently impose constraints on the creation of software programs by fixing the set of options that are available to the developer. For example, if the graphical programming method lacks a pre-defined solution for some desired functionality, then that functionality either cannot be implemented or its implementation would require such effort as to render the graphical programming method impractical as a programming tool. To solve this problem, the present invention is directed to a program-development environment that allows developers to seamlessly switch between a graphical programming paradigm and a textual programming paradigm. The developer can thus choose the particular paradigm best suited for creating each aspect of the desired program.
The program-development environment of the present invention generates a graphical user interface (GUI) that may be displayed on the screen of a computer system. The GUI has several elements including a form window and a designer window having a toolbar identifying a plurality of available control objects. The control objects are basically software modules having pre-defined properties, methods and events that are configured to perform some useful function. The form window is configured to receive instantiations of one or more control objects selected by the developer from the toolbar, and the designer window is configured to display a symbolic representation of those control objects residing in the form window. According to the invention, these symbols can be linked together by the developer in the form of a data flow or block diagram that logically represents the flow of data and control information into, out of, and between the selected control objects. The flow diagram logically corresponds to the application program being generated.
Specifically, the development environment includes a displayable wire construct that may be used by the developer to graphically link the symbolic representations of the control objects appearing in the designer window. These symbols, moreover, include one or more terminals each of which is associated with pre-defined properties, methods or events of the corresponding control in the form window. Preferably, the developer connects one end of the wire construct to a terminal of a first control object symbol (referred to as the xe2x80x9csourcexe2x80x9d control) and the second end to the terminal of a second control object symbol (referred to as the xe2x80x9csinkxe2x80x9d control). The selected terminal of the source control is associated with an event of the source control and often, but not always, a source control property, and the selected terminal of the sink control is preferably associated with at least a property of the sink control. In response to linking the two control object symbols with the wire construct, the development environment generates a corresponding event handler within the software program. This event handler is called during run time whenever the source event occurs, and it involves affecting the specified sink object""s property in some manner.
The development environment further includes means for calling-up a code window in which the developer may write event handler procedures or code (e.g., a subroutine procedure) using textual inputs for any of the control objects or wire constructs placed on the form window and appearing in the designer window. The development environment inserts all such textual code-based event handlers into the same program as the event handlers generated in response to the graphical input. Thus, the software program generated by the software development environment of the present invention contains event handlers based on the textual code written by the developer as well as event handlers created solely by graphically linking control object symbols with the displayable wire construct. Accordingly, developers can switch back and forth between highly flexible textual code-based event handlers and easy-to-use xe2x80x9cgraphicalxe2x80x9d event handlers during programming.
The wire construct of the present invention also includes several novel features. Specifically, the wire construct itself has a plurality of properties, methods and events. Wire properties, moreover, are set to default values by the program-development environment in order to implement desired event handling characteristics. Nonetheless, the developer, at any time during program development, may direct the system to display the properties, associated with a selected wire construct. The developer may then change the values of these wire properties as desired. In response, the program-development environment modifies the software program accordingly. Furthermore, using the code window, the developer may write one or more text-based event handlers or subroutine procedures that are responsive to the events raised by a selected wire construct. Such event handlers or subroutine procedures are also incorporated as part of the software program for execution during run time.